REQUEST FOR PRODUCTION RELEASES:
To request your PR to be included in production software, please add the corresponding labels called "async-" to your PR. Add the labels directly (if you have the permissions) or add a comment of the form (note that labels are separated by a ",")

+async-label <label1>, <label2>, !<label3> ...

This will add <label1> and <label2> and removes <label3>.

The following labels are available
async-2023-pbpb-apass4
async-2023-pp-apass4
async-2024-pp-apass1
async-2022-pp-apass7
async-2024-pp-cpass0
async-2024-PbPb-apass1
async-2024-ppRef-apass1
async-2024-PbPb-apass2
async-2023-PbPb-apass5

One thing I do not understand from the discussion of yesterday: why don't we use a separate file for the trackQA?

Hello @ddobrigk and all

I have read your source code from pull request and discussed with Felix possible ways to reduce the data volume while still enabling thinning in a controlled, physics-motivated manner. We will need a combination – all associated as you did, plus a fiducial cut for the remaining non-associated events. Removing or downsampling non-associated events prevents us from recovering efficiency.

At the moment, TPC standalone tracks constitute roughly ~50% of all tracks.

Physics motivation for keeping a subset of TPC-only tracks

For tracks above a certain momentum, many TPC-only tracks are close to primary tracks and are useful for association and efficiency studies. In particular, we observe a population of nice, long TPC tracks that carry relevant information.

For example, the following diagnostic plot:

O2track_iu->Draw(
  "fTPCNClsFindable:fTgl>>his(100,-2,2,155,0,155)",
  "fX<20 && fX>60 && fTPCInnerParam>0.8",
  "colz"
);

shows two clear bands in the (NCls, tgl) plane:

• One band corresponds to the geometric effect: the majority of tracks are fully reconstructed in the TPC.
• Additional bands correspond to tracks that are not prolonged from OROCs to IROCs (or vice versa), or that are split at sector / boundary transitions.

These latter tracks are exactly the ones we want to recover, as removing them introduces systematic biases in efficiency and acceptance, especially at the boundaries.

Expected recovery fraction after fiducial cuts

If disk space constraints force us to remove part of the TPC standalone tracks, a large fraction of the useful ones can still be recovered using fiducial and quality cuts.

From a preliminary inspection, about ~35% of TPC standalone tracks pass a tight fiducial volume and kinematic selection, which targets the region we actually want to recover:

O2track_iu->Draw(
  "abs(fSigned1Pt)>5 && abs(fTgl)<1.2",
  "fX>20",
  ""
);

This suggests that we can significantly reduce the total TPC-only sample, while keeping the physics-relevant subset needed to control systematic uncertainties.

Conclusion

• Blind downsampling of TPC-only tracks is not optimal.
• A selection-based thinning (pT, DCA, NCls, fiducial cuts) preserves the tracks that matter.
• Even under strong volume constraints, we can recover O(30–40%) of the useful TPC-only tracks, which is sufficient to stabilize efficiency systematics.

I will follow up with a quantitative estimate on recent Pb–Pb production to provide concrete numbers.

Best regards,
Marian

One thing I do not understand from the discussion of yesterday: why don't we use a separate file for the trackQA?

The key question for me is whether such TrackQA data can then be used in standard physics analyses.

At the moment, several analyses are struggling with suboptimal efficiencies (an dEdx) compared to Run 1 and Run 2, as well as with mismatches between efficiency&PID in MC and in data. These issues are not only QA-related; they directly impact physics results.

For this reason, TrackQA-level information should, in my view, be accessible in the standard physics analysis workflow, not restricted to internal QA-only studies. Otherwise, we lose an important handle to understand and correct efficiency effects, especially in Run 3 conditions.

If TrackQA is moved to a separate file, it is important to clarify:

• how it would be linked back to the physics AO2D, and
• whether it would be officially supported and usable in physics analyses.

Without that guarantee, separating TrackQA risks making it unavailable exactly where it is most needed.

@miranov25, I thought this PR is supposed to modify the fraction of preserved tracks/trackQA in the current Pb2025 production, in which case there is no time for extra tuning.
As for using trackQA to correct the analysis: afaik, so far its usefulness was not demonstrated, and it will certainly decrease with prescaling/thinning.

Hello @shahor02 , @ddobrigk and @f3sch

• Disclaimer – I have not run the code recently; my comment is based on reading the code and the current Ao2D analysis.

From what I have seen, David implemented a switch for the associated tracks in the following way:
If the track is associated, downsampling is not applied.

bool writeQAData = o2::math_utils::Tsallis::downsampleTsallisCharged(data.getTrackParam(trackIndex).getPt(), mTrackQCFraction, mSqrtS, weight, distr(mGenerator)) || (src != GIndex::TPC && mTrackQCKeepGlobalTracks);

However, later the selection criteria are applied independently of the source:

          // include specific selection of tpc standalone tracks if thinning is active
          if (mThinTracks && extraInfoHolder.isTPConly && !writeQAData) { // if trackQA is written then no check has to be done
            auto trk = data.getTPCTrack(trackIndex);
            if (trk.getNClusters() >= mTrackQCNCls && trk.getPt() >= mTrackQCPt) {
              o2::dataformats::DCA dcaInfo{999.f, 999.f, 999.f, 999.f, 999.f};
              o2::dataformats::VertexBase v = mVtx.getMeanVertex(collisionID < 0 ? 0.f : data.getPrimaryVertex(collisionID).getZ());
              if (o2::base::Propagator::Instance()->propagateToDCABxByBz(v, trk, 2., mMatCorr, &dcaInfo) && std::abs(dcaInfo.getY()) < mTrackQCDCAxy) {
                writeQAData = true; // just setting this to not thin the track
              }
            }
          }        

This is what I mentioned in the parallel email thread. Moreover, we will need one more parameter for the Tgl selection. We have a q/pt cut, but not an fTgl cut.

I see two items in the pull request to be added to enable the functionality or cuts I suggested:

• Do not apply the fiducial cut if (src != GIndex::TPC && mTrackQCKeepGlobalTracks)
• Add the tgl cut

With these two changes, we can proceed.
If we do not want to change the code before the 2025 productions, we can simply apply the qpt cut (without the tgl cut). We should be able to do this without modifying the code. I am not the author of the thinning code – perhaps Felix can confirm (@f3sch). I only read that part of the code; I have not run it recently.

Marian

Hi @miranov25 - let's not mix everything up. Please prepare a new, separate pull request with any changes you want to add and we discuss one thing at a time. Thank you!

This has been tested to work fine and is ready for review. I have only changed the default to "false" as a last action item.

Hi @miranov25 - let's not mix everything up. Please prepare a new, separate pull request with any changes you want to add and we discuss one thing at a time. Thank you!

When do you plan to merge? I do not want to modify the code before you merge. I assumed it would be simpler to make modifications in the same pull request. Otherwise, other switches will be ignored, as I wrote above. And we will need more tess.